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Chapter A 

General Information 



The Assembly Execution Read Only Memory (ROM) has been provided to you so that you can 
load and execute assembly language programs which have been written using the Assembly 
Execution and Development ROM. When installed, the Execution ROM reserves 198 16-bit 
words of read/write memory if the I/O ROM is present and 266 words if the I/O ROM is not 
present. This read /write memory cannot be accessed for storage of programs or data. 

It is assumed throughout this manual that you are familiar with the basic operation and lan- 
guage of the 9845. It is not necessary, however, that you be in any way familiar with the 
Assembly Development ROM itself in order to use the Assembly Execution ROM or this man- 
ual. AH of the capabilities provided by the Assembly Execution ROM are in the form of BASIC 
language extensions and are used as any other BASIC statement may be. 



Equipment Supplied 



The following items are supplied with the Assembly Execution ROM 



Item 



Assembly Execution ROM manual 
Error Label 



Part Number 



09845-91082 
7120-8770 



1 The assembly lanauaae caDabilitu is not available for the Sustem 45A Comouter. 
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Purpose of the ROM 



The Assembly Execution ROM (HP part number 98438A) is used to load, store, and execute 
assembly language routines written using the Assembly Development ROM. 

The routines are provided by HP in some instances, or are created by others. Instructions for 
the effective use of the routines themselves are the responsibility of the people (the "authors") 
who developed those routines. Thus, when calling a routine (or even deciding which routine to 
call) consult the documentation provided by the authors of the routine. 



Buzzwords 

During the course of the discussion in this manual, phrases are used which are in common 
circulation in the computer industry. While the meaning of most are either well-known or 
deducible from the context, there are a few which may be new to the user not exposed to 
assemblers before — 

bit — the most elementary unit of computer information. It can assume one of two possi- 
ble states, usually designated as "0" or "1". 

byte — a group of 8 binary digits (bits) operated upon as a unit. 

interrupt service routine (ISR) — an assembly language routine intended to perform a 
certain action, or set of actions, when the computer receives a request from an external 
device. An "active" ISR is one which is currently enabled for a given device. 

word — two bytes, or a group of 16 binary digits (bits) operated upon as a unit. 
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The syntax conventions used in this manual are those used in the Operating and Programming 
manual for the 9845 — 

All syntax items displayed in dot matrix should appear within 
your program as shown. 

[ ] Items contained in brackets are optional items. 

Ellipses mean that the previous item may be repeated indefi- 
nitely. 

In addition, the following convention is employed through the Assembly Language series of 
manuals — 

{ } Items contained in braces are items considered as units. The 

names inside the braces are descriptive of the function in- 
tended for the item. Whenever an item enclosed in braces 
appears in the text, the notation refers to the same notation 
within an earlier syntax. 
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ROM Installation 

The Assembly Execution ROM provides you with the statements necessary to run assembly 
language programs. The ROM must be properly installed before using the statements. The 
installation is a simple process. 

The Assembly Execution ROM is contained in one physical package (HP part number 98438A). 
The ROM is placed in the right ROM drawer with the following steps: 

1. Pull the right ROM drawer out. 

2. Squeeze the sides of the plastic cover and lift to gain access to the drawer connectors. 

3. Position the ROM over one of the connectors denoted by a O marking as shown here - 




4. Press the ROM onto the ROM drawer connector so that it seats all the way down. The 
small circular keys on the sides of the ROM drawer should fit into the recesses in the 
bottom of the plastic ROM case. If they don't, make sure that you have properly oriented 
the ROM. 

5. Snap the plastic cover shut and slide the ROM drawer back until it is flush with the 
computer housing. 

6. Turn on the power and verify operation of the 9845 with the System 45 test. 

7. Install the Assembly Execution ROM error messages sticker on the option error pull-out 
card located under the CRT. 



Chapter £* 

Modules and Routines 



There are three basic activities associated with using assembled routines and modules. First, 
there is the need to retrieve them from wherever they may be stored (including providing a 
place for them to be kept while they are resident in the memory of the machine). Second, there 
is the actual use of a module, or of the routines which it contains. And third, there is the 
occasional requirement to store, or re-store a module on mass storage (including, perhaps, the 
need to free the space in memory it previously occupied). 

This chapter deals which these activities. It demonstrates how you can, within a BASIC prog- 
ram (or from the keyboard), use modules which have been previously created. The fundamen- 
tal statements involved are — 

ICOM used to set aside memory to hold modules and routines 

ILOAD used to retrieve modules from mass storage 

ICALL used to access routines like a subprogram 

ISTORE used to save modules on mass storage 

IDELETE used to free space in memory for other modules 



6 Modules and Routines 



Modules vs. Routines 

What is the difference between a "module" and a "routine"? 

• A routine is a program intended for your use. It is callable, like a subprogram, once it is in 
memory. 

• A module is a collection of one or more routines which are closely associated to one 
another and are considered as a unit. One or more modules may be stored on a file on 
mass storage. 

Names 

Routines, modules, and files all have names. The names given them may or may not bear some 
significance to one another; that depends upon the authors of the routines, and you. 

The names of routines and modules are given to them by the authors of the routines. The 
documentation provided you should indicate the names with which you need to be concerned. 
You may not change these names. 

The naming of files is flexible. Originally, the names were assigned by the authors of the 
routines. They may have been subsequently changed by others. In addition, you may change 
them, depending upon your own needs and desires. Conventions for file names and methods 
for file manipulation can be found in the Operating and Programming manual and in the Mass 
Storage Techniques manual. 



Overview 

To briefly sketch the functional relationships of modules and routines, please refer to Figure 2. 

Modules are stored in files and may be retrieved and placed in memory using the "ILOAD" 
command. When the ILOAD command is executed all of the modules in the file are loaded into 
the memory. Note that many files can be loaded, with many modules each. 

Alternatively, modules which are already in memory may be stored into a single file using the 
"ISTORE" command. When the ISTORE command is executed, the designated modules are 
stored away into an OPRM file (for tape cartridges) or an ASMB file (on non-tape mass storage 
media). After storage, the modules are still in memory. They may be removed (i.e., the space 
they occupy in memory is "freed up") by using the "IDELETE" command. 
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Figure 2. Overview of Routines and Modules 



The area of memory where the modules are stored is called the "ICOM region". It is a particu- 
lar contiguous area which must be large enough to hold all of the modules which you want to 
have in memory at any one time. 



Each module contains one or more routines for your use. The number varies, depending upon 
what the author of the routines has provided you. Your access to the routines is through the 
ICALL statement, which is very similar to the CALL statement used for BASIC subprograms. 
The ICALL statement may have parameters (arguments) which you need to "pass" (send 
down) to the routine itself. What these parameters may be and what meaning they hold 
depends upon what the author had in mind. You can find out that information in the documen- 
tation provided with the routine itself. 
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Setting Aside Memory 



As indicated by Figure 2, you cannot load a module until there is an ICOM region into which to 
load it. 

The statement to use to create an ICOM region is — 

J. CUrl {size} 

where {size} is a non-negative integer constant indicating the number of words to be used to 
form the ICOM region. The maximum size is 32 718 words. 

The ICOM statement is a "declaration"; that is, it can only be included as a line in a BASIC 
program, and cannot be executed from the keyboard. This is similar to a DIM or COM state- 
ment. The actual region is created when the program is run. 

Once created, the ICOM region remains in existence until it is explicitly destroyed. But it is 
possible to change the size by using another ICOM statement later. 

The order in which modules appear in the ICOM region is determined by the order in which 
they are loaded using the ILOAD statement discussed in the next section. 

In most cases, the space which is freed up by reducing the size of the ICOM region, is returned 
to your available memory space. Sometimes, however, it is not returned, depending upon the 
status of common (the area created by the COM statements executed to that point) and other 
option ROMs. The space will be returned whenever — 

• There was never common in existence; or, 

• SCRATCH C has been executed on existing common and no COM statement has been 
executed since then; and, 

• The requirements of another option ROM, which may be present, do not interfere. 

There may be any number of ICOM statements in a program. The current size of the ICOM 
region is determined by the last one which appears in the program when the [™A key is pressed 
(or the command RUN is executed). The region continues to exist even if you load in another 
program which contains no ICOM statements. All ICOM statements must appear in the main 
program only, not in any subprogram. 
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For example, suppose you have a program with the following statements in it — 



Upon pressing [«™j the ICOM region would be 2 000 words long. This is because line 610 is the 
final ICOM appearance. 

All ICOM statements in a program must appear before any COM statement. This is to assure 
that the ICOM region is allocated before the common is allocated. 

If, after running this program, you loaded in another program with no ICOM statements in it at 
all, the ICOM region is still there (with the full 2 000 words). 

There are only two ways to completely eliminate an ICOM region — 

• Execute SCRATCH A. 

• Execute ICOM in a program. 

After either of these, the region is no longer in existence. If there are any modules in the region, 
they disappear as well. If any of those modules contain an active interrupt service routine, you 
get an error (number 193) if you try to eliminate the region using ICOM 0. The documentation 
provided on the routines you have loaded should tell you if there are any such active ISRs. 

The ICOM procedure can be used in a program to assure that all previous modules are 
deleted. For example, the following sequence — 



oooiivjmc +V>o,4- r*r> Tf OM ^*n./-rt *-\r\ /~vf r»rn^ir/Ti1ii Q 000 ntAync ic in nvic+nn^n o+ + r\ y-i vimninrr /~\f mo 
UOOU1CO L11GIL Gill 1W/1*1 lC^lUU \J I JlCV^lOCiy £* \J\J\J WU1UO lO 111 CAlOLCli^C. CI L LUC 1 UllJlUiy \-/l LUC 

program, and one completely clear of any previously loaded modules. 
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When you are altering the size of the ICOM region, the new size specified becomes the size of 
the region from the moment of running the program. If the size being requested is larger than 
that which already exists, the additional space needed is requested from the operating system. 
If the space is available, everything proceeds uneventfully. If the space is not available, an error 
(number 2) results. To make the space available, one of the following procedures must be 
followed — 

• Execute SCRATCH A. 

• Execute SCRATCH C. 

Each procedure has its separate effects, and the course selected should be determined by your 
circumstances at the time. Consult the Operating and Programming Manual for details of the 
other effects of each of these commands. 

If the size being requested is smaller, modules are deleted if they no longer fit into the smaller 
region. For example, suppose the following situation existed — 



■old" ICOM size 



module 
A 


module 
B 


1 

module 

C 
1 


module 
D 


module 
E 



new" ICOM size ■ 



Upon execution of the new ICOM statement, the modules E, D, and C are deleted. None of 
those modules may contain an active interrupt service routine or an error results (number 193). 
The documentation provided on the routines should tell you if there are any active ISRs. 
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Modules are stored in files on mass media as Option ROM (OPRM) or Assembly (ASMB) types 
of files. On tape media, they are stored in the OPRM type and on non-tape media they are 
stored in the ASMB type. The two file types are equivalent. 1 

To retrieve a module, or modules, from mass storage, identify the file name of the file contain- 
ing the module. Combine the name with the mass storage unit specifier (MSUS) of the device to 
form a file specifier. 2 Then execute the statement — 

{file specifier} 

This retrieves ALL the modules in the file and stores them in the ICOM region. 

If there are modules already loaded in the ICOM region, these additional modules are added to 
them (not written over them). If an existing module in the ICOM area has the same name as one 
of the modules being loaded, the existing module is deleted and the loaded version takes its 
place. 

If you do not want all the modules in a given file, but instead just a few, you can purge the 
unwanted ones from the ICOM region using the IDELETE statement — 

;.. {module name} [, {module name} [, ...] ] 



For example, if you had loaded a file which had the modules Larry, Pat, Ed, and Piper, and you 
want to keep only Larry, then you execute the statements — 



or, more simply — 



1 Some OPRM-typc files are not assembly language files, but are created by other option ROMs available on the System 45. 
However, for those that are assembler files, they are exactly equivalent to the ASMB -type. 

2 For a full discussion of file specifiers, consult the Operating and Programming Manual or the Mass Storage Techniques 
manual. 
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Deletions do not have to be done immediately after loading. They can be done at any time. 
After the IDELETE has been executed, the portion of the ICOM region which it previously 
occupied is made available for use in loading another module. The space is NOT returned to 
the generally available memory; that action is done with an ICOM statement with a smaller size. 

Whenever a module is deleted, other modules are moved, as necessary, to take up any slack 
space in the ICOM region. This is done so that all of the free space in the region is at the end. If 
a module is being deleted, or being moved as above, and it contains an active interrupt service 
routine, an error results (number 193). The documentation provided on the routines should tell 
you if there are any active ISRs. 

Of course, to use the IDELETE statement, you must be aware of the module names. Your 
source for finding these names must be the documentation provided by the authors of the 
modules. No error results when an IDELETE statement is used to delete a non-existent module. 

If you desire at any time to delete all of the modules in your ICOM region, you can do so by 
executing either of the following statements — 



Storing Modules 



Sometimes you may desire to move modules in the opposite direction — from memory to mass 
storage. This is done with the ISTORE statement. The statement has the form — 

ISTuRE {module name} [~, {module name} [= ...] ] ;; {file specifier} 

A {module name} must be the name of a module currently stored in the ICOM region. Upon 
execution of the statement, a file with the name and msus given in the {file specifier} is created 
and the modules named are stored in the file, in the order listed. 

The file created by an ISTORE statement is an OPRM or ASMB type, as appropriate to the 
medium involved. The file can then be used in ILOAD statements at a later time. 

In the case that you might want to store all of the routines currently in the ICOM region into a 
particular file, you should use either of the following statements — 

:; {file specifier} 
{file specifier} 
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A module may contain one or more routines for your use. Which routines a given module 
contains should be documented by the author of those routines. Once the module has been 
loaded, all of its routines are immediately available to you through the ICALL statement. This 
statement has the form — 

{routine name} [ ( {argument} [, {argument} [~ ...] ] ) ] 



This ICALL is very much like the CALL of a subprogram in BASIC. If there are arguments 
required by the routine, the requirements for them should be detailed in the documentation for 
the routine provided by the routine's author. It is necessary, when using arguments, that you 
follow the rules for them laid down by the author of the routine. 

Thus, for example, if an author stated the following — 

"The SORT routine requires one argument, the array identifier 
of the string array to be sorted." 

then the ICALL statement to be used would probably look something like this — 

ICALL Sort (Temp$(*)) 

Upon execution of the ICALL statement, execution transfers to the routine named. Upon 
completion of execution of the routine, control is returned to the BASIC statement following 
the ICALL. This is identical in effect to the CALL statement in BASIC. 
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Chapter O 

Handling Interrupts 



An "interrupt" is a request for service from a device connected to the computer. The actual 
type Oi service using requesteu uepenus upon tue uevice. For instance, some uevices senu 
interrupts when they have some information they want your program to take, other devices 
send them when they want some information from your program. How you handle them 
depends upon what the device wants. 

An assembly language routine which you are using may have the capability of handling inter- 
rupts from external devices. It may also inform your BASIC program of special conditions 
detected during the processing of an interrupt, e.g., end of interrupt service, input data error, 
etc. You, in turn, may take this information and cause a branch to another part of your 
program. 

To determine whether the routine you are using handles interrupts, you should consult the 
documentation provided with the routine by the authors of the routine. The documentation 
should tell you what kind of interrupts to expect and what kind of special processing ("hand- 
ling") may be required, if any, on the part of your program. 
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Branching on Interrupts 



Since interrupts are a program-independent occurrence, the handling of an interrupt is some- 
times a reason for causing the program to suspend whatever it is doing and do something else 
(i.e., "branch"). Like the ON KEY statement (see the 9845 Operating and Programming 
Manual), there are three ways these branches can be taken — 

# {select code} [, {priority} ] CFiLI {subprogram name} 

# {select code} [ , {priority} ] {line identifier} 
"H" {select code} [ ;i {priority} ] GOTO {line identifier} 

These statements are provided by the ROM in order to allow the assembly language routine to 
signal your BASIC program that a special condition has arisen and to indicate where it came 
from. When you have executed an ON INT statement and an interrupt occurs, the following 
sequence ensues — 

1. The assembly language routine assigned to the interrupting select code services the 
interrupt. 

2. If the assembly language ISR is so programmed, it signals BASIC that an interrupt 
occurred on the select code of the ISR's choosing (which may not be the one where the 
interrupt actually occurred). 

3. Upon completion of the current BASIC line, the ON INT for the select code with the 
assembly language ISR defined interrupt is honored and the branch indicated for it (be it 
a CALL, GOSUB, or GOTO) is taken. 

In the GOTO version, the branch is "absolute" , which is to say that your program will go to the 
line indicated and pick up its execution there, forgetting where it was before. This has the effect 
of an "abortive" type of branch, and should be used only when you want the program to 
resume execution at some pre-determined point after handling the interrupt, without regard to 
where the program was before the interrupt occurred. 

In the CALL and GOSUB versions, the branch is only temporary. After the subprogram or 
subroutine has been executed and the SUBEXIT, SUBEND, or RETURN (as appropriate) has 
been executed, then the program will return to the line following the one where it was inter- 
rupted. This is the same as if the CALL or GOSUB was in between the interrupted line and the 
one following it. 
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i ne {line iaentirier} ana {suoprogram name} in tne LrtLL, uu^ud, ana uu i u statements are 
the same as elsewhere in BASIC, except that a CALL may not have any parameters. 

The {select code} you specify with the statement restricts the branching action to occurring only 
when the assembly language triggers the ON INT condition for that select code. The interrupt 
may have occurred in actuality on any select code and the assembly language routine may 
decide under some circumstances to have triggered the ON INT with some other select code 
value. This can be a way of allowing more than one branch for interrupts from a single 
interrupting device. 

As an example — 

' -j jT-i \~k ■ )■■'"')■>., i '.' T f- i T 44- O '"~" ;'""'■■ CS ! O "T" - '; . „ ■ ' ._ _. _■ s ■ ._ . 
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Should an interrupt occur anywhere in the program, causing the assembly language routine to 
indicate select codes 2 or 7, the subroutine "Take_reading" would be performed and then 
resume program execution at the point of interruption. Should an interrupt be received from 
select code 12, then the subprogram "Process data" would be performed. 
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Prioritizing Interrupts 



Since more than one interrupt may occur while a single BASIC statement is executing, it is 
possible that by the time the line finishes you may have a number of ON INT branches waiting 
to be executed. In such situations you may want to assure that some ON INT branches are 
taken before others, or that you finish one routine (caused by an ON INT GOSUB or ON INT 
CALL) before you start another. This can be achieved by using the {priority} option of the ON 
INT statement, thereby "prioritizing" the branching caused by interrupts. 1 

There is a "system priority" number for ordering this interrupt branching. For an ON INT to be 
honored at the end of a BASIC line, its priority must be greater than the current system priority. 

Initially, the system priority is set to 0. When a BASIC line finishes, and there is at least one ON 
INT branch pending which is greater than the system priority, then the system will take the 
branch associated with the ON INT with the greatest {priority}. The values assigned to {priority} 
may be any integer numeric expression from 1 to 15. If {priority} is omitted, 1 is assumed. 

If the ON INT branch to be executed is a GOTO, then the system priority level is unchanged. 
But if the branch to be executed is a GOSUB or a CALL, then the system priority level is 
changed to the priority level of the ON INT. Whenever the subroutine or subprogram is finished 
executing, then the previous system priority level is restored. 

Thus, with the GOSUB and CALL versions, there are two effects involving priorities — 

• The subroutine or subprogram is not allowed to execute until its priority is the highest one 
pending. 

• Whenever the subroutine or subprogram is executing, it locks out any other interrupting 
branches unless they have a higher priority. 

With the GOTO version there are also two effects, slightly differing — 

• The branch is not taken until it has the highest priority of all pending branches. 

• The execution of the branch does not lock out any other branches, so that at the end of 
the line to which it branches, if there are other pending branches, the highest one of those 
will then be executed. 



This "prioritizing" also holds between the various types of end-of-line branch statements that have the priority parameter. 
Thus an ON KEY with high priority will be executed before an ON INT with low priority. 
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For example, suppose there are these four statements in effect — 



and also suppose that at the end of some BASIC line in the program, an interrupt had 
been received from all four of the interfaces involved. Then the process of dealing with 
them would proceed like this — 



EVENT 


NEXT ACTION 


SYSTEM PRIORITY 


Reaches end of current 


GOSUB Routine_7 


Changes from to 15 


BASIC line 






Finishes Routine 7 


GOSUB Routine_5 


Changes from 15 to 9 






EVENT 


NEXT ACTION 


SYSTEM PRIORITY 


Reaches end of current 


GOSUB Routine_7 


Changes from 9 to 15 


BASIC line in Routine 5 






Finishes Routine 7 


Returns to interrupted 
point in Routine 5 


Changes from 15 to 9 


Finishes Routine 5 


GOTO 1000 


Changes from 9 to 


Finishes with line 1000 


GOTO Routine_4 


Stays at 
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Environmental Considerations 

Changes in program environment, i.e., calling a subprogram or returning from one, can affect 
whether an ON INT is in effect or not. 

The CALL version of an ON INT is always in effect, whether in the main program or in any 
subprogram. 

In the GOSUB or GOTO versions, the statement is in effect only in the same program 
environment. This is to say that if you have executed an ON INT statement in your main 
program, then it is effective only while your program is executing part of the main program. The 
instant the program goes into a subprogram (through a CALL statement), the statement is no 
longer effective until the execution returns to the main. Similarly, if you define an ON INT in a 
subprogram, it is effective only while the program is executing that subprogram. 

A side-effect occurs here when you use the CALL version of an ON INT. By calling the 
subprogram with an ON INT, you have the effect of locking out the other interrupts, except 
those which are executed in the subprogram itself and other CALL versions. This is regardless 
of priority. In the priority example in the previous section, if the ON INT#5 had been a CALL 
instead of a GOSUB, then the second interrupt from select code 7 would not have been 
acknowledged until the subprogram had finished. 

Since recursive calls of subprograms are possible, it is also possible that many calls to the same 
subprogram may be stacked up because an interrupt from a different select code with a CALL 
version of an ON INT in effect may be received while processing the CALL caused by a 
previous interrupt. 
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The branching enabled by an ON INT statement can be disabled using an OFF INT statement 
for the same select code. It is effective for the ON INT statement within the same program 
environment (main program or subprogram) or for the CALL versions of the ON INT within any 
environment. 

The statement has the form — 

I {select code} 

where {select code} is a numeric expression for any valid interface select code between 1 and 
13, inclusive. 

The effect of the OFF INT statement is to disable the ON INT for that select code within the 
current environment. If there is no ON INT statement currently in effect for the select code, 
then the OFF INT will have no effect. 

DISABLE and ENABLE deactivate and activate, respectively, the ON INT as well as the ON 
KEY and ON KBD declaratives. 
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Chapter *r 

Errors and 
Error Processing 

While you are using or accessing an assembly language routine, it is possible that an error may 
occur which is associated with your attempts to use the routine. It is intended that this chapter 
give some guidance as to how certain errors can be handled. It is not a definitive checklist of 
what can go wrong, nor is it an exhaustive treatment of the means to correct the difficulties 
which are listed. Rather it is meant as a reference for some of the things which can go wrong, 
what might cause them, and how to deal with them. Each programmer has a unique method of 
approaching the problem of error processing and there is no way to anticipate all of them. Even 
so, the following should offer some assistance in identifying the source of an error. 

Not every machine error is covered here — only those directly related to accessing and using 
assembly language routines. A complete listing of error messages can be found in Appendix A. 

The following list is of the messages you may receive should there be an assembly language- 
related problem of some sort. Possible corrective actions are included in the discussion of each 
error. 



ROM missing, or configuration error. To operate the System 45, all system 
ROMs and the Assembly Execution ROM must be in place. Perform the 
system test if the problem persists. 

Memory overflow. You may have specified an ICOM which is too large for 
your current available space. Things to try to get things to fit: select a 
smaller ICOM size; execute SCRATCH C (if no important data remains in 
common), delete modules and reduce the ICOM size; segment your pro- 
gram. The error may also be caused by trying to load modules which are too 
large for the current ICOM region or by placing a COM statement before an 
ICOM statement. 

The number of arguments passes by an ICALL statement exceeds the 
number of parameter declarations in the subroutine entry section. 
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Doubly-defined entry point or routine. A module being assembled (with an 
IASSEMBLE statement) or loaded from mass storage (with an ILOAD 
statement) contains a SUB or ENT entry point with the same label as a SUB 
or ENT entry point within a module already resident within the ICOM reg- 
ion. Check the other routines for the duplicate occurrences. 

No ICOM region found. You have failed to create the ICOM region, or have 
inadvertently deleted it. Program an ICOM statement of adequate size and 
re-run the program. 

Module not found. The module indicated in an ISTORE statement is not 
currently resident in the ICOM region. Check your module names used in 
the statement to find the one which is missing. 

Attempt to move or delete module containing an active interrupt service 
routine. This is the result of trying to reduce the size of the ICOM region (or 
to eliminate it), or trying to delete a module, when one of the affected 
modules has an active interrupt service routine. The only ways to allow the 
action to take place are to SCRATCH A (which affects a number of other 
things), to press ^^(stopJ, or to inactivate the ISR. To inactivate the ISR, 
consult the routine's documentation. 

Routine not found. You may have specified the wrong routine name or 
failed to load the correct module. Double check the documentation indicat- 
ing the location and name of the routine. 

Unsatisfied externals. You may not have loaded all of the modules neces- 
sary to run the routine. Double check the routine's documentation for the 
other resources you may need. May be an error in the programming of the 
module, in which case check with the routine's author. 

Missing COM statement. The routine you have called is expecting to find or 
place some of its data in common, and you have not provided the COM 
statement required. Check the documentation for the routine to determine 
the common requirements. 

Common area does not correspond to module requirements. The routine 
you have called is expecting to find or place some of its data in common, 
but your COM statement does not match up the variables correctly in either 
type or size. Check the documentation for the routine to determine the 
common requirements. 
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Insufficient number of items in BASIC COM declarations. The routine you 
have called is expecting to find or place some of its data in common, but 
your COM statement does not provide enough variables to satisfy the 
routine's needs. Check the documentation for the routine to determine the 
common requirements. 
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Appendix i\ 

Error Messages 



Missing ROM; or configuration error 

Memory overflow; or subprogram larger than block of memory 

Line not found or not in current program segment 

Improper return 

Abnormal program termination; no END or STOP statement 

Improper FOR/ NEXT matching. 

Undefined function or subroutine 

Improper parameter matching 

Improper number of parameters 

String value required 

Numeric value required 

Attempt to redeclare variable 

Array dimensions not specified 

Multiple OPTION BASE statements or OPTION BASE statement preceded by 
variable declarative statements 

Invalid bounds on array dimension or string length in memory allocation 
statement 

Dimensions are improper or inconsistent; or more than 32 767 elements in an 
array 

Subscript out of range 

C.U „*...•„„ ~..+ „f ..-,„„« i_:„„ 4.„~ 1 

juusuniy (jul ui laiiye ui suniy iuu luny 

Improper value 
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Integer precision overflow 

Short precision overflow 

Real precision overflow 

Intermediate result overflow 

TAN (n*7r/2), when n is odd 

Magnitude of argument of ASN or ACS is greater than 1 

Zero raised to negative power 

Negative base raised to non-integer power 

LOG or LGT of negative number 

LOG or LGT of zero 

SQR of negative number 

Division by zero; or X MOD Y with Y = 

String does not represent valid number; or string response when numeric data 
required 

Improper argument for NUM, CHR$, or RPT$ function 

Referenced line is not IMAGE statement 

Improper format string 

Out of DATA 

EDIT string longer than 160 characters 

I/O function not allowed 

Function subprogram not allowed 

Improper replace, delete or REN command 

First line number greater than second 

Attempt to replace or delete a busy line or subprogram 

Matrix not square 

Illegal operand in matrix transpose or matrix multiply 

Nested keyboard entry statements 
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No binary in memory for STORE BIN; or no program in memory for SAVE 

Subprogram COM declaration is not consistent with main program 

Recursion in single-line function 

Line specified in ON declaration not found 

File number less than 1 or greater than 10 

File not currently assigned 

Improper mass storage unit specifier 

Improper file name 

Duplicate file name 

Directory overflow 

File name is undefined 

Mass Storage ROM is missing 

Improper file type 

Physical or logical end-of-file found 

Physical or logical end-of-record found in random mode 

Defined record size is too small for data item 

File is protected or wrong protect code specified 

The number of physical records is greater than 32 767 

Medium overflow (out of user storage space) 

Incorrect data type 

Excessive rejected tracks during a mass storage initialization 

Mass storage parameter less than or equal to 

Invalid line number in GET or LINK operation 

(See Mass Storage ROM errors) 

Cartridge out; or door open 

Mass storage device failure 

Mass storage device not present 
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Mass storage medium is write protected 

Record not found 

Mass storage medium is not initialized 

Not a compatible tape cartridge 

Record address error; or information can't be read 

Read data error 

Check read error 

Mass storage system error 

(See Mass Storage ROM errors) 

Item in PRINT USING list is string but IMAGE specifier is numeric 

Item in PRINT USING list is numeric but IMAGE specifier is string 

Numeric field specifier wider than printer width 

Item in PRINT USING list has no corresponding IMAGE specifier 

(See I/O ROM errors) 

(Unused) 

(See Graphics ROM errors) 

(See I/O ROM errors) 

(Unused) 

(See I/O ROM errors) 

(Unused) 

(See I/O ROM errors) 

(See Assembly Development ROM errors) 

(See Assembly Language ROM errors) 

(See Assembly Development ROM errors) 

(See Assembly Language ROM errors) 

(See Assembly Development ROM errors) 

(See Assembly Language ROM errors) 
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octal numoer ;; octal number 



This error indicates an error in the machine's firmware system; it is a fatal error. If reset 
does not bring control back, the machine must be turned off, then on again. If the problem 
persists, contact your Sales and Service Office. 



Mass Storage ROM Errors 

Format switch off 

Not a disk interface 

Disk interface power off 

Incorrect controller address, controller power off, or disk access time-out 

Incorrect device type in mass storage unit specifer 

Drive missing or power off 

Disk system error 

Incorrect unit code in mass storage unit specifier 

(Unused) 

(Unused) 



Graphics ROM Errors 

Plotter type specifications not recognized 
Plotter not previously specified 
CRT Graphics hardware not installed 
LIMIT specifications out of range 
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I/O ROM Errors 

ON KBD or TOPEN not allowed in subprogram. 

98036 card improperly configured. 

TDISP not allowed unless peripheral keyboard active. 

TOPEN is active on another select code. 

Improper select code. 

A negative select code was specified that does not match present bus address- 
ing. 

Parity error. 

Either insufficient input data to satisfy enter list, attempt to ENTER from 
source into source or enter count exhausted without linefeed. 

Integer overflow, or ENTER count greater than 32 767 bytes or 16 383 words. 

Invalid interface register number. (Can only specify 4-7.) 

Improper expression type in READIO, WRITEIO, or STATUS list. 

No linefeed was found to satify / ENTER image specifier, or no linefeed 
record delimiter was found in 512 characters of input. 

Improper image specifier or nesting image specifiers more than 4 levels deep. 

Numeric data was not received for numeric enter list item. 

Repetition of input character more than 32 768 times. 

Attempted to create CONVERT table or EOL sequence for source or destina- 
tion variable which is locally defined in a subprogram. 

Attempted to delete a nonexistent CONVERT table or EOL sequence. 

I/O error, such as interface card not present, device timeout, interface or 
peripheral failure (Interface FLAG line = 0.), stop key pressed or improper 
interface card type. 

Transfer type specified is incorrect type for interface card. 

A FHS or DMA transfer with no format specifies a count that exceeds th size of 
the variable, or an image specifier indicates more characters than will fit in the 
specified variable. 
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A NOFORMAT FHS or DMA type transfer does not start on an odd numbered 
character position, such as A$[3]. 

Interface status error, TRL Character or an EOI was received on an HP-IB 
Interface before ENTER list or image specification was satisfied. 

Improper argument for OCTAL or DECIMAL Function. 



Assembly Language ROM Errors 

Doubly-defined entry point or routine. 

Missing ICOM statement. 

Module not found. 

Attempt to move or delete module containing an active interrupt service 
routine. 

Routine not found. 

unsatisfied external symbols. 

Missing COM statement. 

Common area does not correspond to module requirements. 

Insufficient number of items in Basic COM declarations. 
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Appendix D 

Maintenance 



Maintenance Agreements 

Service is an important factor when you buy Hewlett-Packard equipment. If you are to get 
maximum use from your equipment, it must be in good working order. An HP Maintenance 
Agreement is the best way to keep your equipment in optimum running condition. 

Consider these important advantages — 

• Fixed Cost — The cost is the same regardless of the number of calls, so it is a figure that 
you can budget. 

® Priority Service — Your Maintenance Agreement assures that wou receive nrioritu treat- 
ment, within an agreed-upon response time. 

• On-Site Service — There is no need to package your equipment and return it to HP. Fast 
and efficient modular replacement at your location saves you both time and money. 

• A Complete Package — A single charge covers labor, parts, and transportation. 

• Regular Maintenance — Periodic visits are included, per factory recommendations, to 
keep your equipment in optimum operating condition. 

• Individualized Agreements — Each Maintenance Agreement is tailored to support your 
equipment configuration and your requirements. 

After considering these advantages, we are sure you will see that a Maintenance Agreement is 
an important and cost-effective investment. 

For more information, please contact your local HP Sales and Service Office. 
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Assembly Execution ROM 

see ROM, Assembly Execution 
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GOSUB 16 

GOTO 16 
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i 



Bit, defined 2 

Braces, use in syntax 3 

Brackets, use in syntax 3 

Buzzwords 2 

Byte, defined 2 



CALL 16-20 

COM 8-9,24,25 

Common 8,24,25 
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Dot matrix, use in syntax 3 



e 

Ellipses, use in syntax 3 

Equipment Supplied 1 

Errors: 23-25 

Messages 27-33 

Execution ROM 

see ROM, Assembly Execution 
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Files: 6,7,11-12 

Names 6 



ICALL 5,7,13 

ICOM: 

Region 7,8,12,23,24 

Statement 5,7,8,23 

IDELETE 5-7,11,12 

ILOAD 5-7,8,11,12 

Installation, ROM 4 

Interrupt service routine 10,16,24 

Interrupt service routine, defined 2 

Interrupts: 15-21 

Branches 16 

Branches, disabling 21 

Priorities 18 

ISTORE 5,6,7,12,24 
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Mass storage 5-7,11-12 

Modules: 

Assembled 5-7 

Errors 25 

Names 6 

Retrieving 11,12 

Storing 12 
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Names: 

Files 6 

Modules 6 
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OFF INT 21 

ON INT 16-21 



r 

RETURN 16 

ROM: 

Assembly Execution 1,4,23 

Drawers 4 

Errors 23 

Installation 4 

Option 8 

Routines: 

Accessing 7,13 

Assembled 1,5-7,24 

Interrupt service 10,16,24 

Interrupt service, defined 2 

Names 6 
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SCRATCH A 9,10,24 

SCRATCH C 8,10,23 

SUBEND 16 

SUBEXIT 16 

Subprograms, BASIC 16,20 

Syntax, fundamental 3 



W 



Word, defined 2 



Your Comments, Please. 



Your comments assist us in improving the usefulness of our publications; they are an important 
part of the inputs used in preparing updates to the publications. 

In order to write this manual, we made certain assumptions about your computer background. 
By completing and returning the comments card on the following page you can assist us in 
adjusting our assumptions and improving our manuals. 

Feel free to mark more than one reply to a question and to make any additional comments. 

Please do not use this form for questions about technical applications of your system or re- 
quests for additional publications. Instead, direct those inquiries or requests to your nearest HP 
Sales and Service Office. 

If the comments card is missing, please address your comments to: 

HEWLETT-PACKARD COMPANY 

Desktop Computer Division 

3404 East Harmony Road 

Fort Collins, Colorado 80525 U.S.A. 

Attn. Customer Documentation 
Dept. 4231 

All comments and suggestions become the property of Hewlett-Packard. 



Comments Card for the Assembly Execution ROM Manual 



Yourself 



1. What is uoiir mainr annliratinn nf the .Susrpm 45? 



2. What was your level of programming knowledge before you started using this manual? 
O none O beginner O intermediate O expert 



The Manual 



1. Did you have any difficulty in: 

understanding material in manual? 
applying that information? 



one 


minimal 


some 


considerable 


O 


O 





O 


O 


O 


O 


O 



2. How would you rate the: 



u. 





excellent 


good 


fair 


poc 


areas covered 


o 





O 


o 


depth of coverage 


O 


o 


o 


o 


examples 


o 


o 


o 


o 


indexing 


o 








o 


organization 


o 


o 


o 


o 


overall manual 


o 


o 


o 


o 



What do you suggest we do to improve the areas that you consider weak? 



The Method 



1. By which method would you have preferred to learn the use of the System 45? 

O Present set of manuals 

O Manuals using programmed-learning approach 

O Training workbooks with corresponding tape cartridge 

O Manuals resident in computer's memory, accessible through the keyboard and displayed on the CRT 

O Training in classroom situation at Hewlett-Packard 



General comments: 
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Assembly Language ROM Errors 

Doubly-defined entry point or routine. 

Missing ICOM statement. 

Module not found. 

Attempt to move or delete module containing an active 
interrupt service routine. 

Routine not found. 

Unsatisfied external symbols. 

Missing COM statement. 

Common area does not correspond to module require- 
ments. 

Insufficient number of items in BASIC COM declarations. 
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